Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

put local channel behind user-specified channels, for remote priority #3038

Merged
merged 2 commits into from
Jul 24, 2018

Conversation

msarahan
Copy link
Contributor

@msarahan msarahan commented Jul 20, 2018

fixes #3036

Channels specified via --channel, -c on the CLI, or channel_urls (in the API) will take priority over locally built packages. Locally built packages still take priority over anything configured in condarc.

@msarahan msarahan force-pushed the allow_channels_ahead_of_local branch from 43bfeb1 to d4b9c75 Compare July 20, 2018 20:51
@mingwandroid
Copy link
Contributor

@msarahan, local priority should be the default here if people do not specify it, for those wanting a different order they should specify that explicitly I think.

@msarahan
Copy link
Contributor Author

@mingwandroid local is still the default, because the channel list is empty without any -c argument. Prior to this PR, it was impossible to put anything before local. This PR only makes that possible.

@mingwandroid
Copy link
Contributor

mingwandroid commented Jul 21, 2018

Doesn't this change mean it's no longer the case that people who use -c (like I do, for every build) will have local appear first in the list? It requires them to add it themselves which will break peoples' workflows (and it'll also appear last in the list, pointlessly).

@msarahan
Copy link
Contributor Author

If you put it for every build, why don't you put it in condarc instead? There has to be a way for people to put channels ahead of local. You know I never want to break your workflow, but this is crippled right now. I can put this behind a flag, I guess, but having the split between CLI-specified things and condarc things makes sense to me.

@msarahan
Copy link
Contributor Author

Anyway, not going to rush this into the next release, since it is contentious.

@msarahan
Copy link
Contributor Author

@Bezier89 @mingwandroid I think this is better now. This will preserve existing behavior when local is not one of the manually specified channels. However, it should now be possible to put some other channel ahead of local by specifying both the other channel and local as arguments:

conda build -c somechannel -c local somerecipe

will put somechannel ahead of local, while

conda build -c somechannel somerecipe

will not.

@@ -73,9 +71,18 @@ def get_build_index(subdir, bldpkgs_dir, output_folder=None, clear_cache=False,
log_context = partial(utils.LoggingContext, logging.CRITICAL + 1)
capture = utils.capture

# priority: channels passed as args, local (can vary with either croot or output_folder),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should update this comment to reflect the new change in behavior.

if os.path.isdir(output_folder):
urls.insert(0, url_path(output_folder))
if 'local' in urls:
Copy link
Contributor

@Bezier89 Bezier89 Jul 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine as is, but this is 1 line shorter. Use whichever you prefer:

if 'local' not in urls:
    urls.insert(0, 'local')
urls[urls.index('local')] = url_path(output_folder)

@msarahan msarahan force-pushed the allow_channels_ahead_of_local branch from dc20fde to 0a13cb3 Compare July 24, 2018 21:11
@msarahan msarahan merged commit 919e1ef into conda:master Jul 24, 2018
@msarahan msarahan deleted the allow_channels_ahead_of_local branch July 24, 2018 22:00
@github-actions
Copy link

Hi there, thank you for your contribution!

This pull request has been automatically locked because it has not had recent activity after being closed.

Please open a new issue or pull request if needed.

Thanks!

@github-actions github-actions bot added the locked [bot] locked due to inactivity label Apr 19, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Test environment incorrectly prioritizes local channel
3 participants